Many enterprise data processing systems rely on multi-node database servers to store and manage data. Such enterprise data processing systems typically follow a multi-tier model that has a multi-node database server in the first tier, and one or more computers in the middle tier and outer tiers.
FIG. 6 depicts multi-node database server mds11, which is implemented on multi-tier architecture 10. A server, such as multi-node database server mds11, is a combination of integrated software components and an allocation of computational resources, such as memory, a node, and processes on the node for executing the integrated software components on a processor, the combination of the software and computational resources being dedicated to performing a particular function on behalf of one or more clients. Resources from multiple nodes in a multi-node computer system can be allocated to run a particular server's software. A particular combination of the software on a node and the allocation of the resources from the node is a server that is referred to herein as a server instance or instance. Thus, a multi-node server comprises multiple server instances that can run on multiple nodes. Several instances of a multi-node server can even run on the same node.
A database server governs and facilitates access to a particular database, processing requests by clients to access the database. A multi-node database server, such as multi-node database server mds11, comprises multiple “database instances”, each database instance running on a node. Multi-node database server mds11 governs access to database db11. A multi-node database server can govern and facilitate access to one or more databases.
The middle-tier of multi-tier architecture 10 includes middle-tier computer cmp11 and the outer-tier includes user computer cmp12. User computer cmp12 executes browser br11, which interacts with an end-user. The end-user's interaction with browser br11 causes the browser to transmit requests over a network, such as the Internet, to middle-tier computer cmp11. The request causes a process on middle-tier computer cmp11, client c11, to execute application appl11. Execution of application appl11 by the client c11 causes client c11 to connect to multi-node database server mds11. For example, application appl11 may be an order entry application that is configured to receive order requests from browser br11. Data for the order entry application is stored in db11. To process the requests, execution of application appl11 by client c11 causes client c11 to connect to database db11. Once connected, client c11 issues database statements to retrieve and manipulate data stored in database db11.
The tier that directly connects to a server, relative to other tiers in a multi-tier architecture, is referred to herein as containing the client of the server. Thus, client process c11 is referred to herein as the client of multi-node database server mds11.
An application, as the term is used herein, is a unit of software that is configured to interact with and use the functions of a server. In general, applications are comprised of integrated functions and software modules (e.g. programs comprised of machine executable code or interpretable code, dynamically linked libraries) that perform a set of related functions.
An application, such application appl11, interacts with a multi-node database server mds11 via client-side interface component intcomp11. Execution of application appl11 causes client c11 to execute client-side interface component intcomp11 to interact with multi-node database server mds11. Application appl11 includes invocations of routines (e.g. functions, procedures, object methods, remote procedures) of client-side interface component intcomp11. Applications are typically developed by vendors and development teams different from those that develop servers and interfaces to servers, such as multi-node database server mds11 and client-side component intcomp11.
In order for a client to interact with multi-node database server mds11, a session is established for the client on a database instance of multi-node database server mds11. A session, such as a database session, is a particular connection established for a client to a server, such as a database instance, through which the client issues a series of requests (e.g., requests for execution of database statements).
For each database session established on a database instance, session state is maintained for the session. Session state includes the data stored for a database session for the duration of the database session. Such data includes, for example, the identity of the client for which the session is established, and temporary variable values generated by processes and database components executing software within the database session. A database component is a set of software modules that provide specialized and related functions for a database server, and shall be described later in greater detail. An example of a database component is a Java execution engine.
The beginning and end of a session demarcates a unit of work. Often, the beginning of a database session corresponds to an end-user establishing an interactive session with an application via, for example, a browser, and ends when the end-user logs off. Thus, the beginning and ending of the database session depend on application logic and end-user action, and may not be controlled by a server on which the session is established.
Client-Side Interface Components
Client-side interface components, such as client-side interface component intcomp11, are software components that reside and are executed on the same computer of a client of a server, and that are configured to provide an interface between the client and the server. The client-side interface component intcomp11 is configured for performing the detailed operations needed to interface with multi-node database server mds11. For example, an application appl11 invokes a function of client-side interface component intcomp11 to establish a connection to multi-node database server mds11. The client-side interface component then handles the details of a connection on a particular instance of multi-node database server mds11. To make requests of multi-node database server mds11, such as a request for execution of a query, application app11 is configured to invoke functions of client-side interface component intcomp11, which then transmits a request for the same to the node and database instance on which the session is established.
Client-side interface component intcomp11 may generate and/or access state that is hidden from other software modules, that is, is not or may not be referenced and accessed by other software modules, and in particular, by application appl11. Such state is referred to as being internal or private to client-side interface component intcomp11.
For example, to create a database session on a multi-node database server mds11, application appl11 invokes a routine of client-side interface component intcomp11. The client-side interface component establishes a database session on a particular database instance within multi-node database server mds11, and stores details about the database session within internal data structures or objects. Such data structures and objects define, for example, the session established for an application, and specify such values as an identity of a session on a database instance, the name of the database instance, and a network address and port number for the connection to the database instance.
Such details of the session are not returned to application appl11, nor may application appl11 access the details. Instead, what is provided to application appl11 is an “external identifier” for the session, such as a value that internal data of client-side interface component intcomp11 maps to the session, or a reference to an object generated by client-side interface component intcomp11 to store some details of the session in private attributes of the object that are inaccessible to application appl11. In this way, application appl11 does not “know” of the specific details of the session that has been established for it; however, application appl11 has the information needed to be able to identify to client-side interface component intcomp11 the particular session that has been established for application appl11.
Distributing Workload
An important capability needed to manage multi-node database servers is to distribute workload between the nodes. Distributing workload is used to improve performance, by optimally balancing workload between nodes. Distributing workload also allows work to be shifted from a node that is being taken off-line for maintenance operations to another node.
Different techniques may be employed to migrate or move a session from one instance to another instance. Numerous patent applications identified in the section entitled “Related Application Data” discuss various techniques for migrating sessions from one node of a multi-node system to another node of the multi-node system. Briefly, to migrate a session (“the original session”) from a first instance on a first node to a second instance on a second node, the second node is identified by the entity that is initiating the migration. A new session (“the migrated session”) is created on the second node. Session state information may then be transferred from the original session to the new session so that the new session on the second node reflects the same state as the original session on the first node. Thereafter, the migrated session on the second node is used in lieu of the original session to perform the work that would have been performed in the original session.
Messaging Systems
A process within a session may interact with a variety of database objects. A database object may be used to implement a queue of messages. In such a case, the queue of messages is accessible to all server instances that can access the database maintaining the queue of messages.
A queue of messages may be used to implement a messaging system. In a messaging system, a queue contains messages, which may be (a) added to the queue (or “enqueued”) by publishers, or (b) removed from the queue (or “dequeued”) by subscribers or recipients. When a queue is implemented using a database object, a database may maintain a queue by storing information about the queue in a table. A publisher may enqueue a message into a queue by inserting a row into a table implementing the queue. A subscriber may dequeue a message from the queue by selecting and/or deleting a row from the table. Various techniques for implementing a queue of messages are described in the patent application referenced in the Related Application Data section entitled “Buffered Message Queue Architecture for Database Management Systems.”
When a process within a session interacts with a queue of messages, the session state reflects how many messages have been queued or dequeued from the queue. In this way, the proper behavior of the queue is ensured. However, when a session, containing session state information that describes the state of a queue, is migrated from one instance to another instance, the session state information describing the state of the queue cannot be preserved during migration to the new session according to the present state of the art. As a result, when a process in the migrated session enqueues or dequeues messages from the queue, the proper behavior of the queue cannot be guaranteed. For example, if a process in the migrated session dequeues a message, a different message may be dequeued from the queue of messages than if the same operation was performed in the original session. Thus, known techniques for migrating a session cannot migrate a session if the session contains queuing state information describing the state of a queue of messages.
Consequently, an approach to migrate a session containing queuing state information that describes the state of a queue is needed in the art. The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.